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ABSTRACT 

The  release  of  CJCSI  3 170.0 1C,  CJCSM  3170.01,  CJCSI  62 12.0 1C,  and  the  related  DoD 
Instruction  5000.2  regarding  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS) 
and  Operation  of  the  Defense  Acquisition  System  have  brought  DoD/C4ISR  Architectures 
(“integrated  architectures”  in  the  respective  documents)  “to  the  forefront”  of  the  acquisition 
process  via  mandate.  However,  when  discussing  “what  constitutes  an  integrated  Architecture,” 
most  often  the  discussion  leads  directly  to  the  DoD  Architecture  Framework  and  its  related 
products.  While  the  Framework  plays  a  large  part  in  providing  a  common  lexicon  by  which  the 
primitives  that  compose  integrated  architectures  are  described,  delving  directly  into 
“spreadsheets  and  boxologies”  misses  the  point  of  why  we’re  creating  integrated  architectures. 
This  paper  will  clarify  the  overarching  purpose  of  integrated  architectures,  provide  associated 
implications  associated  with  the  enterprise  portfolios  into  which  they  fit,  and  describe  a 
methodology  by  which  the  architecture  community  can  improve  the  process  of  developing  and 
maintaining  architectures  in  order  to  meet  the  intent  of  the  Clinger-Cohen  Act  by  providing  the 
means  for  analysis  by  which  one  can  achieve  efficient  distribution  of  limited  resources. 


FOREWORD 


I  fully  recognize  that  in  recommending  to  the  architecture  community:  “architectures  need  to 
provide  information  for  use  in  a  enterprise-wide  Portfolio  Management  system. . that  I’m 
“preaching  to  the  choir”  (for  those  needing  a  primer  on  Portfolio  Management  as  it  relates  to 
systems,  people,  and  things,  it’s  discussed  more  thoroughly  in  the  paper).  However,  I’m 
proceeding  with  it  because  I  believe  the  current  vision  with  respect  to  the  creation  of  the  various 
architecture  repositories  within  the  respective  commands,  services,  and  agencies  is  myopic  in 
that  they’re  only  looking  for  a  “correct,  from  an  engineering  perspective”  description  of  their 
respective  enterprises.  While  this  is  definitely  a  step  in  the  right  direction,  and  would  potentially 
save  the  acquisition  community  from  having  to  recreate  architecture  artifacts  from  scratch 
(thereby  saving  the  DoD  millions  of  dollars  each  year),  it’s  only  a  small  part  of  the  equation 
regarding  what’s  called  for  by  the  Clinger-Cohen  act.  In  fact,  the  only  thing  it  realistically 
allows  us  to  do  is  “more  efficiently  create  more  architectures.” 

I  am  not  arguing  the  fact  that  there  are  benefits  from  being  able  to  more  efficiently  create  and 
integrate  disparate  architectures.  However,  I  submit  that  we  need  to  take  a  more  holistic 
perspective  with  regard  to  creating  these  repositories;  the  repositories  need  to  be  constructed 
with  the  following  requirements  in  mind: 

•  The  repositories  need  to  be  created  for  use  across  communities  and  across  domains;  this 
“strategic  information  asset  base”  (i.e.,  the  enterprise  portfolio)  needs  to  be  designed  for 
use  by  all  the  respective  stakeholders  in  the  Doctrine,  Materiel,  Training,  Leadership, 
Personnel,  and  Facilities  (DOTMLPF)  equation,  to  include  the  financial  aspects  related  to 
making  decisions. 

•  Each  “enterprise”  needs  to  realize  it’s  a  smaller  part  of  a  larger  enterprise  (and  potentially 
multiple  enterprises);  therefore,  these  enterprise  portfolios  need  to  be  designed  such  that 
they  can  feed  higher-echelon  portfolios  in  an  automated  fashion,  with  considerations 
made  for  appropriately  protecting  information  across  the  different  levels  (i.e.,  just 
because  your  program’s  system  is  a  subset  of  an  even  larger  portfolio  management 
system,  it  doesn’t  mean  you  can  see  the  nitty-gritty  funding  details  of  another  program). 

Historically,  intentionally  or  unintentionally,  we’ve  stovepiped  the  architecture,  engineering,  and 
acquisition  process  from  the  other  business-related  entities.  In  doing  this,  we’ve  been  far  too 
shortsighted  —  we  need  to  get  all  the  respective  organizations  connected  and  using  the  same  (or 
at  a  minimum,  “compatible”)  portfolio  management  tools  and  schema.  It  is  vital  to  have  the 
vision  correct  for  accomplishing  this  “in  the  large,”  as  it  represents  the  most  difficult  case  of 
trying  to  build  an  agile  overall  system  by  which  we  defend  the  country.  In  accomplishing 
portfolio  management  “in  the  large,”  we  will  be  accomplishing  what  the  transformation 
community  is  trying  to  do  “in  the  small”  (relatively  speaking)  with  Net-Centricity;  to  build  a 
system-of-systems  that  keeps  us  inside  our  adversaries’  decision  cycles  via  correct  distribution  of 
limited  resources  more  quickly  than  our  adversaries  can  respond. 


EXECUTIVE  SUMMARY 


The  release  of  CJCSI  3170.01C,  CJCSM  3170.01,  CJCSI  6212.01C,  and  the  related  DoD 
Instruction  5000.2  regarding  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS) 
and  Operation  of  the  Defense  Acquisition  System  have  brought  DoD/C4ISR  Architectures 
(“integrated  architectures”  in  the  respective  documents)  “to  the  forefront”  of  the  acquisition 
process  via  mandate.  However,  when  discussing  “what  constitutes  an  integrated  Architecture,” 
most  often  the  discussion  leads  directly  to  the  DoD  Architecture  Framework  and  its  related 
products.  While  the  Framework  plays  a  large  part  in  providing  a  common  lexicon  by  which  the 
primitives  that  compose  integrated  architectures  are  described,  delving  directly  into 
“spreadsheets  and  boxologies”  misses  the  point  of  why  we’re  creating  integrated  architectures. 
This  paper  will  clarify  the  overarching  purpose  of  integrated  architectures,  provide  associated 
implications  associated  with  the  enterprise  portfolios  into  which  they  fit,  and  describe  a 
methodology  by  which  the  architecture  community  can  improve  the  process  of  developing  and 
maintaining  architectures  in  order  to  meet  the  intent  of  the  Clinger-Cohen  Act  by  providing  the 
means  for  analysis  by  which  one  can  achieve  efficient  distribution  of  limited  resources. 

The  Framework  defines  Architecture  as:  “...The  structure  of  components,  their  relationships, 
and  the  principles  &  guidelines  governing  their  design  &  evolution  over  time...  ”  While  the 
guidance  channels  are  different,  I  believe  the  Federal  Chief  Information  Officer  (CIO)  Council’s 
definition  to  be  clearer  regarding  what  architectures  are,  and  their  intended  use:  “...  a  strategic 
information  asset  base,  which  defines  the  mission,  the  information  necessary  to  perform  the 
mission  and  the  technologies  necessary  to  perform  the  mission,  and  the  transitional  processes  for 
implementing  new  technologies  in  response  to  the  changing  mission  needs...”  It  goes  on  further 
to  state:  “. . .  The  primary  purpose  of  an  Enterprise  Architecture  is  to  inform,  guide,  and 
constrain  the  decisions  for  the  enterprise,  especially  those  related  to  IT  investments ...  ” 

As  such,  I  believe  the  primary  purpose  of  Integrated  Architecture  is  to  provide  the  means  by 
which  an  organization  manages  the  portfolio  of  resources  within  its  span  of  control,  to  include  all 
aspects  of  doctrine,  organization,  materiel,  personnel,  and  facilities  (DOTMLPF).  This 
“integrated  strategic  information  asset  base”  must  provide  the  following: 

•  Multiple,  interrelated  Operational  Views  (OVs),  for  each  Concept  of  Operations 
(CONOPs)  accomplished  by  the  enterprise  (i.e.,  desired  CONOPs-based  capabilities). 

o  These  CONOPs  should  form  the  basis  by  which  doctrine  is  recorded  and 
analyzed;  therefore,  those  performing  the  function  of  creating  and  updating 
doctrine  are  both  stewards  and  users  of  this  “strategic  information  asset  base” 
o  Thus,  the  portfolio  needs  to  provide  information  to  the  tools  and  language 
familiar  to  end  users  from  several  different  domains 

•  For  each  CONOPs,  the  ability  to  map  multiple  System-of-Systems  (SoS)  and  Family-of- 
Systems  (FoS)  solutions  (i.e.,  Systems  Views)  to  each  CONOPs.  This  includes: 

o  Current  Systems  within  the  Portfolio 
o  Programmed  Systems  within  the  Portfolio 
o  New/Proposed  Systems 

•  The  means  by  which  to  perform  analysis  for: 

o  Each  individual  CONOPs  and  related  Operational  Views: 

■  Available  SoS/FoS  Solutions 


■  Optimal  SoS/FoS  Solutions 

o  The  aggregate  of  all  CONOPs  within  the  scope  of  the  Enterprise 

■  Available  SoS/FoS  Solutions 

■  Optimal  SoS/FoS  Solutions 

The  vision  of  this  “integrated  strategic  asset  base”  is  still  in  its  formative  stages.  There  are 
bodies  of  work  in  the  Joint  Staff  and  the  services  moving  us  towards  this  vision,  but  the 
processes  aren’t  being  designed,  from  the  start  to  feed  information  into  the  overall  Joint/DoD 
Strategic  Information  Portfolio.  This  is  absolutely  needed  to  facilitate  JCIDS  Functional  Needs 
Analyses  as  well  as  Functional  Solutions  Analyses. 

The  architecture  community  is  making  strides  towards  this  vision,  but  there  are  areas  where  the 
community  can  improve: 

•  ASD/NII  and  the  Air  Force  have  efforts  underway  to  create  an  architecture  repository 
called  the  DoD  Architecture  Repository  System  (DARS);  this  is  a  step  in  the  right 
direction,  but  it  DARS  at  this  point  is  only  intended  to  store  architecture  information,  and 
not  tie  to  other  domain’s  information  (unless  specifically  included  in  an  architecture 
product).  This  being  said,  DARS  will  help  the  acquisition  community  by  allowing 
program  offices  to  construct  the  following  query:  “SELECT  *  FROM  Systems  WHERE 
My_System  (or  like  systems)  is  the  sender  or  recipient  of  information.” 

o  This  information  is  absolutely  key  to  the  creation  and  enterprise-wide  agreement 
between  OV  artifacts  in  Capability  Development  Documents  (CDDs)  and 
Integrated  Support  Plans  (ISPs). 

o  Current  efforts,  especially  with  regard  to  ISPs/C4ISPs  are  “reinventing  the  wheel” 
every  time  one  of  these  requirements  documents  is  created,  thus  creating  semantic 
mismatches  for  the  same  information,  and  in  the  endgame,  misusing  resources 

•  Most  current  architectures  have  one-and-only-one  Systems  Architecture  to  answer  the 
requirement  outlined  in  the  Operational  Views  within  their  Architecture.  This  is  fine  for 
As-Is/Baseline,  and  individual  program  office  architectures,  but  doesn’t  allow  one  to  do 
analysis  of  optimal  SoS/FoS  mix  for  To-Be/Objective  architectures. 

•  Most  current  architectures’  product  views  don’t  agree  across  product  sets  (known  as 
concordance).  The  products  within  the  OVs  should  be  renderings  of  information  within 
the  same  data  set,  and  thus,  map  to  one  another;  SVs  should  be  renderings  of  the  same 
data  set,  and  maintain  traceability  to  the  requirement  outlined  in  the  OVs. 

Current  concepts  and  technologies  (data  mining/warehousing,  XML,  web  portal  technologies, 
various  decision  management  and  portfolio  management  tools,  application  of  net  centric  warfare 
concepts,  etc.)  will  potentially  enable  the  realization  of  integrated  architecture-driven  enterprise 
portfolios  that  are  truly  “strategic  information  asset  bases.”  These  technologies  will  enable  the 
analysis  of  information  collected  from  different  communities  (C4ISR  Architecture,  current 
system  portfolios,  Modeling  and  Simulation,  Manpower/Personnel,  Doctrine  &  Training,  etc.) 
leading  to  substantial  productivity  gains  via  economies  of  scale,  thereby  meeting  the  intent  of  the 
Clinger-Cohen  Act.  The  “ricebowl”  implications  of  such  a  system  are  enormous,  but  these  must 
be  surmounted  to  realize  this  vision.  This  is  not  a  short-term  process;  however,  a  coherent 
strategy  DoD-wide  will  be  needed  to  make  this  happen.  This  paper  provides  a  strawman  for 
achieving  this  vision. 


DISCUSSION 


Enterprise:  an  organization  (or  cross  organizational  entity)  supporting  a  defined  business  scope  and 
mission.  An  enterprise  includes  interdependent  resources  (people,  organizations,  and  technology)  who 
must  coordinate  their  functions  and  share  information  in  support  of  a  common  mission  (or  set  of  related 
missions).  [A  Practical  Guide  to  Federal  Enterprise  Architecture,  V  1 .0,  Federal  CIO  Council,  Feb  01] 

The  release  of  CJCSI  3 170.0 1C  and  CJCSM  3170.01  regarding  the  Joint  Capabilities  Integration 
And  Development  System  (JCIDS),  CJCSI  62 12.0 1C  Interoperability  and  Supportability  of 
Information  Technology  and  National  Security  Systems,  as  well  as  the  related  DoD  Instruction 
5000.2  regarding  Operation  of  the  Defense  Acquisition  System,  have  brought  DoD/C4ISR 
Architectures  (referred  to  in  the  respective  documents  as  “integrated  architectures”)  “to  the 
forefront”  of  the  acquisition  process  via  mandate.  However,  when  entering  into  a  discussion 
about  “what  constitutes  an  integrated  DoD/C4ISR  Architecture,”  most  often  the  path  leads 
directly  to  discussions  about  the  DoD  Architecture  Framework  and  its  related  products.  While 
the  Framework  plays  a  large  part  in  providing  a  common  lexicon  by  which  the  primitives  that 
compose  integrated  architectures  are  described,  delving  directly  into  “spreadsheets  and 
boxologies”  misses  the  reason  why  we’re  creating  integrated  architectures  in  the  first  place. 

Why  are  we  doing  this  “ Architecture  Stuff...?” 

Even  though  there  have  arguably  been  “enterprise  architecture”  efforts  for  20  years  or  more,  the 
genesis  of  most  current  architecture  efforts  is  the  Information  Technology  Reform  Act 
(ITMRA)  of  1996,  also  known  as  the  Clinger-Cohen  Act.  This  legislation  required  the 
appointment  of  a  Chief  Information  Officer  (CIO),  whose  responsibilities  included  design  and 
implementation  an  IT  Management  process  for  maximizing  the  value  and  assessing  and 
managing  the  risks  of  IT  acquisitions. 


Promote  effective  &  efficient  design  and 
operation  of  all  major  processes 


‘Primary  Duty 


Process  of  managing  inf  ormation  resources  to 
accomplish  agency  missions 

 Develop,  Maintain  &  Facilitate  Implementation 

Integrated  framework  for  evolving  or  maintaining  ■ 
existing  IT  and  acquiring  new  IT  1 

Assess  and  develop  strategic  plans  for 
hiring,  training  and  process  development 

Information  and  related  resources,  such  as 
personnel,  equipment, funds,  and  IT 

Monitor  and  evaluate  performance 

Any  equipment  or  interconnected  system  or 
subsystem  of  equipment,  that  is  used  in  the 
automatic  acquisition,  storage,  manipulation, 
management,  movement,  control,  display, 
switching,  interchange,  transmission,  or  reception 
of  data  or  information  by  the  agency 

Thus,  within  the  U.S.  Government,  various  architecture  frameworks  have  been  developed  to 
provide  the  primitives  with  which  the  business  enterprise  can  be  captured  and  explained.  Within 
the  DoD,  the  C4ISR  Architecture  Framework,  whose  latest  incarnation  has  been  renamed  the 
DoD  Architecture  Framework  and  released  as  a  DoD  Instruction,  has  become  the  chosen  means 
by  which  we  capture  artifacts  about  our  respective  organizations  within  the  DoD.  However, 


information  captured  by  use  of  the  DoD  Architecture  Framework  only  captures  “part  of  the 
picture”  when  it  comes  to  assessing  and  managing  the  risks  of  IT  acquisitions.  What’s  missing? 
This  will  be  elaborated  on  in  the  next  sections. 


Implications  Associated  with  Enterprise  Architectures 

The  DoD  Architecture  Framework  defines  Architecture  as: 

“  ...The  structure  of  components,  their  relationships,  and  the  principles  &  guidelines  governing 

their  design  &  evolution  over  time...” 

While  the  guidance  channels  are  different,  I  believe  the  Federal  Chief  Information  Officer  (CIO) 
Council’s  definitions  and  philosophy  to  be  clearer  with  respect  to  what  architectures  are,  and 
their  intended  use.  A  Practical  Guide  to  Federal  Enterprise  Architecture  defines  Enterprise 
Architecture  (EA)  as: 

"...  a  strategic  information  asset  base,  which  defines  the  mission,  the  information  necessary  to 
perform  the  mission  and  the  technologies  necessary  to  perform  the  mission,  and  the  transitional 
processes  for  implementing  new  technologies  in  response  to  the  changing  mission  needs...  ” 

It  goes  on  further  to  state: 

"...  The  primary  purpose  of  an  EA  is  to  inform,  guide,  and  constrain  the  decisions  for  the 
enterprise,  especially  those  related  to  IT  investments...  ” 

As  such,  even  though  these  frameworks  were  created  with  the  management  of  IT  in  mind,  I 
believe  the  primary  purpose  of  Integrated  Architectures  is  to  provide  the  means  by  which  an 
organization  manages  the  portfolio  of  resources  within  its  span  of  control,  to  include  all  aspects 
of  doctrine,  organization,  materiel,  personnel,  and  facilities  (DOTMLPF).  The  implication  of 
such  a  statement  is  that  each  respective  community  needs  to  be  able  to  reach  into  the  “strategic 
information  asset  base”  (i.e.,  the  Enterprise  Portfolio)  and  get  data  from  the  other  communities 
that  can  be  transformed  into  actionable  information  from  which  decisions  can  be  made. 


Seems  far-fetched,  doesn’t  it?  However,  several  technologies  are  maturing  that  can  make  this 
integrated  architecture-driven  strategic  information  asset  base  a  reality,  including  several  being 
leveraged  for  Net-Centric  warfare.  These  include  such  technologies  as  data  mining/data 
warehousing,  XML,  web  portal  technologies,  various  decision  management  and  portfolio 
management  tools. 

What  do  you  mean  when  you  say  portfolio  management  -  that ’s  what  we  do  with  stocks,  right...  ? 
The  concept  is  very  similar;  portfolio  management,  when  applied  to  an  enterprise,  performs  the 
following  functions: 

•  Tracks  the  “stuff’  in  the  enterprise:  people,  materiel,  systems,  and  facilities 

•  Documents  the  rules  governing  their  interaction  (organization  and  doctrine) 

•  Records  enterprise  evolution  over  time,  including  historical  information  on  use  of  the 
“stuff’  (day-to-day  operations,  training,  exercises,  deployments,  etc.),  current  status,  and 
projections  for  evolution  of  the  individual  parts  of  the  enterprise  over  time: 

o  People:  manning  levels  and  the  respective  levels  to  which  they  are/have  been 
trained 

o  Materiel:  when  and  where  consumables  have  come  from,  and  where  they  are 
expected  to  come  from 

o  Systems:  historical  functionality,  and  expected  functionality  as  new  versions  are 
fielded  (i.e.,  fielding  schedules  across  the  enterprise) 
o  Facilities:  historical  as  well  as  expected  upgrades  to  facilities 

•  Tracks  financial  information  related  to  the  “stuff’  (historical,  current,  and  projected) 

•  Provides  means  to  perform  “what  if’  analyses  regarding  distribution  of  resources: 

o  Diagnostic  tools 
o  Modeling  and  Simulation 


These  technologies  can  enable  the  analysis  of  information  collected  from  different  communities 
(C4ISR  Architecture,  current  system  portfolios  and  their  associated  readiness  data,  Modeling  and 
Simulation,  Manpower/Personnel,  Doctrine  &  Training,  etc.)  leading  to  substantial  productivity 
gains  via  economies  of  scale,  thereby  meeting  the  intent  of  the  Clinger-Cohen  Act.  The 
“ricebowl”  implications  of  such  a  system  are  enormous,  but  these  must  be  surmounted  to  realize 
this  vision.  This  is  not  a  short-term  process;  however,  a  coherent  DoD-wide  strategy  will  be 
needed  to  make  this  happen. 


A  Coherent  DoD-wide  Strategy  -  JCIDS 

This  coherent  strategy  is  the  rationale  behind  the  new  Joint  Capabilities  Integration  and 
Development  Process  (JCIDS).  DoD-wide,  with  the  advent  of  transformation  to  Net-Centric 
Warfare,  we’re  realizing  the  catch  phrase  from  a  computer  vendor’s  advertisement  was,  indeed, 
correct,  and  “way  before  its’  time:” 


. . .  The  Network  IS  the  System . . . 


CJCSI  31 70.01  C  Joint  Capabilities  Integration  and 
Development  Process  (JCIDS): 

Changes  to  31 70.01  B  RGS  MNS/ORD  Process 
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Integrated  Architectures: 


-  Provide  engineering  discipline  to  design  of  the  Enterprise: 

>  Business  Processes  +  Systems  +  Rules  by  which  systems  built... 

>  Constraint:  that  which  one  has  financial  control/influence  over 

-  “Net  Centric”  transformation  enabler:  “raises  the  bar”  on  what  the 
system  is: 


The  Network  IS  the  System ... 
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However,  while  the  JCIDS  process  is  attempting  to  drive  us  to  solutions  that  meet  “the  big 
picture,”  we’ve  still  got  a  long  way  to  go  before  we  reach  the  vision  behind  an  integrated- 
architecture-driven  “strategic  information  asset  base.”  The  architecture-supported  Enterprise 
Portfolio  Management  systems  haven’t  been  coherently  implemented;  thus  we’re  in  a  state  of 
trying  to  manage  our  respective  portfolios  in  much  the  same  “system  of  stovepipes”  fashion  as 
we  always  have,  creating  yearly  drills  at  each  headquarters  with  a  CIO  to  manually  put  the 
information  together  by  which  they,  and  higher  echelons  make  decisions. 


So,  with  the  understanding  that  architectures  are  supposed  to  inform,  guide,  and  constrain 
decisions,  what’s  missing?  Asked  a  different  way,  what  aren’t  we  doing  right?  In  a  nutshell,  the 
architectures  are  not  being  created  for  use  such  that  all  the  various  organizations  within  the 
enterprise  rely  on  them  to  formulate  their  decisions  -  we’ve  not  even  begun  to  scratch  the  surface 
for  creation  of  architecture-driven  enterprise  portfolios  that  are  “strategic  information  asset 
bases.”  We’re  thinking  entirely  too  small  -  instead  of  viewing  architecture  as  providing  the 
structural  input  to  “how  the  enterprise  works”  to  the  “strategic  asset  base,”  we’ve  historically 
thought  of  it  as  “someone  else’s  problem.” 


Historical  Perspective:  Architectures  1996  -  Present 

Since  the  creation  and  maintenance  of  DoD/C4ISR  Architectures  was  aligned  under  the  CIO, 
most  organizations  thought  of  architecture  as  “an  IT  problem.”  This  being  said,  in  the  creation 
of  their  respective  enterprise  architectures,  most  CIOs  were  not  adequately  funded  to  set  up 
anything  approaching  the  vision  of  a  “strategic  information  asset  base.”  Knowing  this,  the 
community  attempted  to  create  a  levy  on  new  systems  within  the  acquisition  process,  mandating 
that  they  create  architectural  artifacts  for  their  respective  programs  that  could  be  aggregated  by 
the  CIO  to  build  the  enterprise  architecture  with  successively  more  current  information  as  time 
went  on.  However,  this  never  happened.  My  opinions  on  this  are  derived  from  having  worked 
both  in  support  of  a  CIO-related  organizations,  as  well  as  in  support  of  program  offices;  my 
impressions  of  the  respective  community  views: 

•  CIO:  all  acquisition  documents  have  to  come  through  my  front  door  for  approval. 
Therefore,  I’m  in  the  best  position  to  ensure  that  the  information  provided  by  the 
programs  fits  into  the  overall  “big  picture”  of  what  the  enterprise  is  doing.  However,  as 
far  as  integrating  all  the  information  in  the  requirements  documents  into  one  cohesive 
whole,  I’m  still  not  funded  for  that.  Additionally,  since  many  of  the  systems  are  not 
under  my  funding  purview,  I  haven’t  got  the  “hammer”  to  modify  aspects  of  individual 
programs. 

•  Acquisition:  What’s  this  “architecture  stuff?”  Hmm ...  C4ISR  Architecture 
Framework...  OK  - 1  can  create  something  that  looks  like  that.  Most  of  this  our  prime 
contractor  has,  but  they’ll  want  us  to  pay  for  it  if  we  ask  them  do  it,  and  that  could  affect 
our  schedule;  we’ll  get  together  our  in-house  graybeards  and  lock  them  in  a  room,  and 
they’ll  be  able  to  knock  it  out  in  a  couple  of  weeks.  What  do  you  mean  contact  the  CIO? 
What  does  the  CIO  have  to  do  with  this?  This  is  the  requirement  for  my  contractor? 
We’ve  already  got  them  under  contract  using. . .  (pick  any  applicable  requirements 
document)  ...  as  the  requirement;  they’re  already  building  the  system  to  those 
specifications,  and  anything  else  that  comes  out  of  architecture  would  cause  us  to  have  to 
modify  the  contract,  which  we’re  not  inclined  to  do  because  that  would  cause  a  new 
contract  to  have  to  be  created,  with  the  associated  schedule  adjustments,  increased  costs 
in  getting  the  contract  approved,  etc. 

This  process  put  the  architectures  at  the  wrong  end  of  the  acquisition  chain;  the  architectures 
didn’t  drive  the  requirements  to  create  the  respective  systems  -  they  ended  up  being  the  product 
of  the  system  being  built  (and  often,  an  afterthought,  after  the  system  had  already  been  built).  As 
such,  there  was  no  integrated  methodology  by  which  program  offices  were  told:  “build  down 


from  here;”  i.e.,  they  weren’t  given  the  operational  requirement  (obtained  by  a  structured 
engineering  driven  gap  analysis)  to  elaborate  upon  using  engineering  techniques,  and  build  the 
system  to  match  those  specifications. 

With  no  overarching  process  by  which  the  individual  program  offices  built  their  respective 
architectures,  in  the  endgame,  aggregation  of  the  information  provided  in  the  program  offices’ 
architectures  proved  impossible.  Even  if  the  respective  CIOs  tried  to  incorporate  the 
architectural  information  into  some  sort  of  centralized  repository,  the  “Acquisition  graybeards” 
made  it  difficult,  especially  regarding  information  exchanges  (which  were  most  times  aggregated 
to  such  a  level  as  to  be  meaningless  to  any  systems  engineer  trying  to  decipher  them), 
operational  nomenclature  (think  of  how  fast  names  of  organizations  change,  and  you’ll  get  the 
picture),  and  systems  nomenclature.  That’s  not  to  say  that  the  products  that  came  out  of  the 
program  offices  were  “wrong”  -  their  creators  just  weren’t  aware  of  the  larger  scale  into  which 
they  fit,  and  that  other  resources  should  have  been  available  to  them  such  that  they  didn’t  have  to 
create  the  information  relating  to  “every  icon  on  the  page”  from  scratch.  Therefore,  what  was 
created  was  a  series  of  “PowerPoint  engineering”  renderings  of  systems,  whose  information 
exchanges  didn’t  match  up  semantically  or  otherwise  with  the  documentation  relating  to  the 
systems  to  which  they  were  connecting,  nor  to  the  doctrine  within  which  these  systems  were 
supposed  to  operate. 

Therefore,  without  an  overarching  structure  into  which  the  individual  program  offices’ 
architectures  were  to  fit,  the  acquisition  document  approval  process  never  included  a  step  that 
utilized  an  enterprise  portfolio  to  perform  the  following  checks  and  balances: 

•  Ensure  agreement  regarding  information  exchanges  (semantic,  timeliness,  and  amount  of 
information  exchanged)  across  the  spectrum  of  all  programs  to  which  the  system  is 
connected 

•  Ensure  the  schedule  regarding  releases,  block  cycles,  and  versions  being  released, 
matches  up  with  the  dependencies  of  other  systems  to  which  the  system  is  connected 

Most  of  this  work,  if  done  at  all,  was  personality-driven  (i.e.,  if  the  person  reading  the  document 
knew  other  programs  being  affected  by  the  system  whose  documentation  they  were  reading, 
maybe  they  could  catch  an  error;  if  not,  the  rigor  of  the  check  was  along  the  lines  of  the 
following:  . . .  lets  see. . .  they’re  supposed  to  have  an  OV-1,  and  OV-3,  and  an  SV-1 . . .  let  me  get 
my  copy  of  the  C4ISR  Architecture  Framework  out. . .  yep,  these  look  like  them. . .  they  look 
OK  regarding  agreement  within  the  document,  so  they  must  be  OK. . .  next!). 

Several  initiatives  in  the  architecture  community  (DoD  Architecture  Repository  System  [DARS], 
Army  Architecture  Repository  Management  System  [AARMS],  Department  of  the  Navy 
Integrated  Architecture  Database  [DIAD],  among  others)  have  sought  to  remedy  parts  of  this 
equation,  but  in  trying  to  solve  the  smaller  problem  of  having  a  reference  database  for 
“architecture  stuff’  that  provides  vetted,  reusable  primitives,  we’ve  had  trouble  achieving  these 
small  steps  towards  the  larger  vision  of  an  “integrated  strategic  asset  base”  due  to  the  following: 

•  The  architecture  databases  haven’t  reached  the  level  of  maturity  by  which  the  acquisition 
community  can  get  the  answer  to  the  following  query:  “SELECT  *  FROM  Systems 
WHERE  My  System  (or  like  systems)  is  the  sender  or  recipient  of  information.” 


o  This  information  is  absolutely  key  to  the  creation  and  enterprise-wide  agreement 
between  OV  artifacts  in  Capability  Development  Documents  (CDDs)  and 
Integrated  Support  Plans  (ISPs  -  the  follow-on  to  C4ISPs) 
o  Current  efforts,  especially  with  regard  to  ISPs/C4ISPs  are  “reinventing  the  wheel” 
every  time  one  of  these  requirements  documents  is  created,  thus  creating  semantic 
mismatches  for  the  same  information,  and  in  the  endgame,  misusing  resources 

•  Most  current  architectures  have  one-and-only-one  Systems  Architecture  to  answer  the 
requirement  outlined  in  the  Operational  views  within  their  architecture.  This  is  fine  for 
As-Is/Baseline  architectures,  but  doesn’t  allow  one  to  do  analysis  of  optimal  SoS/FoS 
mix  for  To-Be/Objective  architectures.  These  analyses  should  be  done  prior  to  new 
program  office  inception,  and  should  be  handed  to  the  program  office  as  the  “up  front” 
requirement  by  which  the  new  system  is  to  be  created. 

•  Many  current  architectures’  product  views  don’t  agree  across  product  sets  (known  as 
concordance).  The  products  within  the  OVs  should  be  renderings  of  information  within 
the  same  data  set,  and  thus,  map  to  one  another;  SVs  should  be  renderings  of  the  same 
data  set,  and  maintain  traceability  to  the  requirement  outlined  in  the  OVs.  Since  the 
guidance  for  creating  the  architectures  wasn’t  clear  on  this  point,  in  most  cases,  the 
architecture  products  were  created  separately  by  different  teams  with  no  interaction.  The 
lack  of  understanding  of  this  key  point  led  to  the  vast  majority  of  architectures  created  to 
become  “shelfware,”  rather  than  creating  information  that  can  be  subsequently  leveraged 
by  other  activities  (program  offices,  doctrine  creators,  financial  management,  etc.)  within 
the  enterprise. 

Since  the  CIO  and  the  program  offices  weren’t  on  same  page  regarding  an  overarching  process 
by  which  architectures  were  being  created,  any  thought  of  having  this  architecture-driven 
“strategic  information  asset  base”  from  which  we  could  pull  information  enterprise-wide  to 
manage  the  enterprise  portfolio  has  simply  been  beyond  our  grasp.  Thus,  the  vision  of  having 
the  organizations  responsible  for  provision  of  Doctrine,  Organization,  Training,  Materiel, 
Personnel,  and  Facilities,  to  include  the  financial  aspects  of  all,  using  the  same  set  of  core 
information  has  never  come  to  fruition. 


So...  What  Does  this  “ Strategic  Information  Asset  Base”  Need  to  Do? 

In  order  to  provide  the  means  by  which  analyses  of  alternatives  can  be  conducted  for  the  JCIDS 
process  (at  the  command,  service,  agency,  or  the  JROC  level),  the  integrated  architecture-driven 
“strategic  information  asset  base”  must  provide  the  means  by  which  the  following  are 
documented: 


Capabilities-Based  Methodology 
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•  Doctrine:  The  enterprise  is  defined  by  the  mission  areas  for  which  it  is  responsible. 
Within  the  JCIDS  process,  these  mission  areas  are  described  via  Concepts  of  Operations 
(CONOPs).  The  CONOPs,  in  turn,  are  described  by  multiple,  interrelated  sets  of 
Operational  Views  (OVs),  for  each  Concept  of  Operations  (CONOPs)  to  be 
accomplished  by  the  enterprise.  These  CONOPs  should  form  the  basis  by  which 
doctrine  is  recorded  and  analyzed;  therefore,  those  performing  the  function  of  creating 
and  updating  doctrine  are  both  stewards  and  users  of  this  “strategic  information  asset 
base.” 


Tying  CONOPs  to  Capabilities 

Relationships  between  OA  and  SoS’s/FoS’s 
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FoS/SoS’s  Matching  the  Respective  CONOPs:  For  each  CONOPs,  the  ability  to  map 
multiple  System-of-Systems  (SoS)  and  Family-of-Systems  (FoS)  solutions  (i.e.,  Systems 
Views)  to  each  CONOPs.  These  include: 
o  Current  Systems  within  the  Portfolio 
o  Programmed  Systems  within  the  Portfolio 
o  New/Proposed  Systems 
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Capability  to  Systems/Programs  Traceability  Matrix 

(SV-5  derivative) 

Of  note  in  making  this  match  FoS/SoS  match  to  CONOPs,  the  DoD  Architecture 
Framework  provides  a  new  product,  which  attempts  to  frame  this  analysis.  The 
Capability  to  Systems/Programs  Traceability  matrix  product  attempts  to  do  this  by 
creating  mappings  between  an  operational  activities  and  system  functions,  described  by 
a  stoplight  colored  circle  to  indicate  the  status  of  the  system  support.  Red  indicates 
functionality  planned  but  not  developed.  Yellow  indicates  either  partial  or  full 
functionality  provided,  but  the  system  has  not  been  fielded.  Green  indicates  full 
functionality  provided  and  system  fielded.  A  blank  cell  indicates  that  there  is  no  system 
support  planned  for  an  operational  activity,  or  that  a  relationship  does  not  exist  between 
the  operational  activity  and  the  system  function.  While  this  answers  the  “first  order” 
question  of  “is  there  a  system  being  developed  that  answers  the  requirements  of  the 
capability,”  it  does  not  answer  the  question  of  “how  effective”  the  FoS/SoS  is  in 
accomplishing  this  capability.  Thus,  this  only  provides  the  “first  step”  towards  the 
analysis  that  the  decision-maker  will  need  to  make  acquisition  decisions. 
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•  Analyze  Capabilities:  the  means  by  which  to  perform  analysis  for: 
o  Each  individual  CONOPs/related  Operational  Views 

■  Available  SoS/FoS  Solutions 

■  Optimal  SoS/FoS  Solutions 

o  The  aggregate  of  all  CONOPs  within  the  scope  of  the  Enterprise 

■  Available  SoS/FoS  Solutions 

■  Optimal  SoS/FoS  Solutions 

The  key  point  here  is  that  in  order  to  perform  a  viable  analysis  of  the  different  SoS/FoS  solutions 
across  all  CONOPs  for  which  an  enterprise  is  responsible,  the  asset  base  must  not  only  contain 
“architecture  data,”  but  information  that  can  be  of  use  to  such  communities  as  modeling  and 
simulation,  doctrine  development,  training  and  leadership  development,  acquisition  support, 
financial  support,  scheduling  information  (including  dependencies  between  individual 
systems/programs),  and  analytical  tools  providing  decision-makers  the  information  by  which  the 
enterprise  portfolio  can  be  managed. 


Implication:  DOTMLPF  Support 
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Examples  of  these  analyses  run  across  the  “total  cost  of  ownership”  DOTMLPF  equation: 

•  Doctrine,  Training,  Leadership:  need  to  use  this  strategic  information  to  provide  the 
documentation,  simulations,  etc.  with  which  the  Warfighter  is  trained 

•  Organization,  Materiel,  Personnel,  Facilities:  need  to  use  the  strategic  information  to 
answer  key  questions  about  their  respective  areas  such  as  “how,”  “who,”  “where,”  “how 
much  (training  required,  materiel  required),”  “how  many  (facilities  required,  personnel 
required),”  etc. 

•  Acquisition:  the  acquisition  community  needs  to  be  able  to  perform  the  following  query: 
“SELECT  *  FROM  Systems  WHERE  My_System  (or  like  systems)  is  the  sender  or 
recipient  of  information.” 

o  This  information  is  absolutely  key  to  the  creation  and  enterprise-wide  agreement 
between  OV  artifacts  in  Capability  Development  Documents  (CDDs)  and 
Integrated  Support  Plans  (ISPs  -  with  the  release  of  CJCSI  62 12.0 1C,  these 
replace  C4ISPs  in  the  acquisition  process) 

o  Current  efforts,  especially  with  regard  to  C4ISPs/ISPs  are  “reinventing  the  wheel” 
every  time  one  of  these  requirements  documents  is  created,  thus  creating  semantic 
mismatches  for  the  same  information,  and  in  the  endgame,  misusing  resources 
o  Net-Ready  Key  Performance  Parameters  (NR  KPP’s)  won’t  answer  this  question 
either;  even  if  we  get  to  the  point  of  “everything  runs  via  publish  and  subscribe,” 
you  need  to  be  able  to  document  what  information  your  system  requires,  what 
information  it  provides,  what  services  it  requires,  what  services  it  provides,  etc. 
Without  the  ability  to  ask  the  “What’s  out  there  already?”  question,  we’re  back  to 
the  “endless  architecture  do  loop”  of  creating  the  information  in  each  program 
office  from  scratch. 


o  Schedule  analysis:  the  ability  to  determine  the  interrelationships  of  individual 
systems  (to  include  the  subsystems  included  in  each  system,  block,  or  version 
upgrade)  is  key  to  overall  management  of  the  enterprise. 

And. . .  due  to  new  technologies  being  able  to  provide  for  many  disparate  systems  to  be 
interconnected  and  provide  each  other  information,  it  doesn’t  necessarily  have  to  be  centrally 
located.  The  “devil  in  the  details”  are  in  the  transforms  of  information;  how  much  information 
are  other  communities  allowed  to  see?  Who  has  access?  These  are  important  issues,  but  all 
surmountable. 

Several  initiatives  are  underway  in  each  of  the  services  to  move  us  along  towards  this  vision. 
Among  these  are  the  Air  Force’s  Capabilities  Review  and  Risk  Assessment  (CRRA)  process,  the 
Army’s  LandWarNet  (formerly  Army  Knowledge  Management),  Navy  Mission  Capability 
Packages/FORCEnet/GEMINII  Assessment  Process  and  Toolset,  as  well  as  the  Joint  Staffs 
JCIDS  Analysis  process  by  which  Functional  Solutions  Analyses  (FSA),  and  Post  Independent 
Analyses  are  conducted.  Each  of  these  presents  logical  constructs  for  achieving  architecture- 
based  analyses,  but  each  of  these,  due  to  the  architectures  not  having  complete  financial, 
scheduling,  etc.  information,  requires  lots  of  manual  processes  to  put  together.  Additionally,  the 
following  statement  from  the  DoD  Architecture  Framework  Deskbook  (VI.  0)  regarding 
“Techniques  for  Using  Architectures”  is  very  telling: 

...  These  analytic  techniques  have  been  developed  within  different  segments  of  the  DoD 
community  and  do  not  reflect  coordinated  community  positions  ... 

In  the  endgame,  how  is  the  JCIDS  process  supposed  to  manage  the  DoD  enterprise  if  the 
respective  processes  aren’t  designed,  from  the  start  to  feed  information  into  the  overall 
Joint/DoD  “strategic  information  asset  base”  portfolio? 
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The  examples  above  document  selected  services’  and  Joint  Forces  Command’s  (JFCOM)  efforts 
with  respect  to  achieving  this  vision.  However,  during  a  recent  architecture  symposium,  one  of 
the  most  telling  slides  came  from  the  Army  (TRADOC),  who  had  overlaid  the  Joint  Forces 
Command  slide  above  with  the  statement  “Where  is  the  Virtual  Overarching  Data  Repository?” 

Therefore,  I  believe  to  achieve  the  vision  of  a  “Virtual  Overarching  Data  Repository”  (i.e.,  the 
“strategic  information  asset  base”  -  the  Enterprise  Portfolio),  we  need  a  comprehensive,  well- 
thought-out  solution  to  bringing  the  enterprise  information  together.  Current  systems  and 
methodologies  are  only  scratching  the  surface  of  being  able  to  accomplish  this  vision.  While 
they  are  beginning  to  solve  problems  within  their  respective  realms,  they  don’t  appear  to  be 
moving  towards  the  vision  of  a  “strategic  information  asset  base”  enabling  portfolio  management 
all  the  way  up  to  the  Joint/DoD  level.  It  is  absolutely  imperative  that  we  delineate  and  move  with 
haste  towards  this  vision  in  order  to  make  best  use  of  our  limited  resources. 


Some  suggested  requirements: 


•  Web-based  Access  to  Disparate  Data  Sources:  across  the  services,  the  organizations 
responsible  for  the  creation  of  doctrine,  the  acquisition  of  systems  and  materiel  to  match 
that  doctrine,  human  resources  to  man  the  systems,  leadership  and  organizations  who 
implement  the  doctrine,  training  of  personnel,  and  the  facilities  at  which  all  these 
functions  reside  are  geographically  scattered.  Therefore,  point  solutions  are  not  a  player; 
I  believe  this  can  access  can  be  achieved  using  web-based  enterprise  knowledge  portal 
technologies  that  leverage  mediation  services  (elaborated  upon  below). 

•  Portfolio  Analysis  and  Management  Tools:  including  the  ability  to  track  and  analyze 
schedule,  finances,  dependencies,  efficacy,  are  needed  at  each  level  of  abstraction  to 
include  program  offices,  major  commands,  warfighting  commands,  services,  agencies, 
and  the  joint  level.  Additionally,  information  within  this  portfolio  will  potentially  be  tied 
to  “multiple  masters.”  Some  examples  of  the  “multiple  masters”  relationship: 

o  Air  Force  Special  Operations  Command  (AFSOC)  is  an  Air  Force  major 
command,  but  is  also  a  component  of  and  force  provider  for  US  Special 
Operations  Command  (SOCOM);  the  same  relationship  holds  true  for  Air 
Mobility  Command  (AMC)  in  regards  to  US  Transportation  Command 
(TRANSCOM).  Similar  relationships  exist  between  components  of  other  services 
and  these  commands. 

o  Multi-service  and  multi-national  programs  will  derive  funding  from  multiple 
sources.  Each  funding  source  will  want  access  to  program  information. 

•  Profile-based  Access  Control:  profile-based  access  will  be  needed  to  keep  access  to 
information  at  a  level  commensurate  with  the  function  of  the  person  or  organizational 
function  accessing  the  information. 

A  portal  is  site  featuring  a  suite  of  commonly  used  services,  serving  as  a  starting  point  and 
frequent  gateway  to  the  Web  (Web  portal)  or  a  niche  topic  (vertical  portal).  Civilian  web  portal 
services  (Yahoo,  MSN,  etc.)  often  include  a  search  engine  or  directory,  news,  email,  stock 
quotes,  maps,  forums,  chat,  shopping,  and  options  for  customization.  An  Enterprise 
Knowledge  Portal  is  an  enhanced  Portal  that: 

•  Is  goal-directed  toward  knowledge  production,  knowledge  integration,  and  knowledge 
management 

•  Focuses  upon,  provides,  produces  and  manages  information  about  the  validity  of  the 
information  it  supplies 

•  Provides  information  about  your  business  and  meta-information  about  the  degree  to 
which  you  can  rely  on  that  information 

•  Distinguishes  knowledge  from  mere  information 

•  Provides  a  facility  for  producing  knowledge  from  information 

•  Orients  one  toward  producing  and  integrating  knowledge  rather  than  information 

Mediation  Services:  in  a  large  enterprise  of  autonomous  systems,  the  definition  of  a  single  set 
of  data  standards  that  are  suitable  for  everyone  is  nearly  impossible.  Individual  systems  were 
built  using  differing  standards,  data  models,  and  technologies  that  best  address  their  individual 
requirements.  To  participate  in  the  greater  enterprise,  there  must  be  a  way  to  bridge  the 


incompatibilities  between  these  individual  IT  environments.  Mediation  services  provide  the 
means  for  translation  of  data  between  different  systems  and  services.  Efforts  associated  with  the 
Global  Information  Grid  (GIG)  Net-Centric  Enterprise  Services  Core  Enterprise  Services  (NCES 
CES)  program  can  be  leveraged  in  this  regard.  The  following  graphic  from  the  Association  for 
Enterprise  Integration  (AFEI)  NCES  Workshop’s  Mediation  and  Discovery  Working  Group 
diagrams  the  solution  space,  as  well  as  potential  vendors  and/or  systems  in  the  solution  space: 


Mediation  Key  Concepts 


Further  information  regarding  the  diagram  above: 

•  Axes  of  Mediation: 

o  Data  Mediation  -  integrating  dissimilar  information 

o  Service  Mediation  -  integrating  dissimilar  services  (i.e.,  integration  of  web-based 
services  available  for  use  network  wide  into  a  new,  larger  information  service) 
o  Across  Providers  -  mediation  involving  many  sources/actors 
o  Single  Provider  -  mediation  involving  a  single  provider/consumer  pair 

•  Types  of  Mediation: 

o  Adaptation:  Used  when  an  invoking  application  cannot  communicate  directly  with  an 
outside  service.  Adaptors  provide  service  mediation  when  systems  need  to 
communicate  point  to  point. 

o  Orchestration:  When  a  service  request  triggers  a  whole  chain  of  events,  orchestration 
services  assemble  and  manage  the  integrated  services  (workflow), 
o  Transformation:  When  an  application  requests  information  that  is  not  available  in  the 
fashion  that  the  requestor  desires,  transformation  services  convert  the  information 
into  the  desired  format. 

o  Aggregation:  Provides  a  central  point  of  interaction  when  requesting  information. 
There  are  usually  multiple  information  sources  points  being  integrated  into  the  single 
point  of  interaction. 


Mediation  Services  will  provide  the  information  required  to  be  gathered  and  transformed  in  order 
for  a  Portfolio  Management  suite  to  be  used  (in  the  above  diagram,  the  Mediation  services 
provided  are  Data  Mediation  -  Transformation  and/or  Data  Mediation  -  Aggregation).  This  of 
course,  assumes  the  Portfolio  Management  suite  doesn’t  already  come  with  some  degree  of 
Mediation  Services  already  bundled  with  it  (the  possibility  of  which  is  indicated  in  the  diagram 
above  by  the  ability  to  orchestrate  processes  requiring  information  that  is  transformed  between 
different  sources  available  to  the  web  portal). 

Regarding  Portfolio  Management  software,  the  top  vendors  within  this  sector  include  ProSight, 
Niku,  Kintana,  Business  Engine,  Pacific  Edge,  and  Primavera.  Of  these,  only  Pacific  Edge, 
Business  Engine,  and  ProSight  were  evaluated  by  the  META  Group  in  a  recent  market  study. 
From  this  study,  ProSight  appeared  to  be  the  best  across-the-board  choice;  ProSight  has  worked 
with  the  Veteran’s  Administration,  Hershey,  as  well  as  many  other  large  corporations,  and  has  a 
product  for  use  with  the  Federal  Enterprise  Architecture  Framework  in  beta.  Regardless  of  the 
vendor  picked  to  implement  the  portfolio  management,  it  needs  to  incorporate  the 
aforementioned  features  in  order  to  work  across  all  echelons,  and  across  all  services  of  the  DoD. 

The  obvious  question  regarding  the  marriage  of  a  Portfolio  Management  system  with  some 
degree  of  Mediation  Services,  to  include  access  controls  on  specific  information,  is  “where  do 
we  start?”  I  recommend  a  pilot  program  be  started  at  JFCOM,  SOCOM,  or  TRANSCOM  in 
order  to  provide  the  multi-service  view  with  multi-service  ownership  of  assets  and  programs 
across  multiple  bases.  Upon  proof  of  concept  of  the  pilot  program,  it  should  be  migrated  DoD- 
wide.  Efforts  including  GIG  NCES  CES  should  be  leveraged  as  much  as  possible  for  this  effort, 
as  there  is  significant  overlap  in  the  basic  functionality  to  be  accomplished,  not  only  regarding 
Mediation  Services,  but  regarding  dynamic  management  of  enterprise  assets  to  complete  the 
mission  and  tasks  at  hand. 

Implementation  of  this,  of  course,  happens  after  we  get  through  the  litany  “it  will  be  too 
expensive  to  implement”  excuses.  To  this,  I  submit  this  reply:  we  can’t  afford  not  to.  We’ve 
been  “doing  architectures”  since  1996,  and  other  than  anecdotal  evidence  of  their  “benefit  to 
society,”  there  is  little  quantifiable  evidence  of  their  utility  beyond  the  “a-ha”  discoveries  made 
during  their  creation  (which,  though  often  very  valuable,  are  not  usually  quantifiable).  Only 
through  the  realization  of  the  “strategic  information  asset  base”  can  we  eventually  get  to  the 
point  where  we  can  definitively  show  the  true  cost  benefit  associated  with  their  accomplishment. 


CONCLUSION 


In  the  endgame,  Integrated  Architectures  are  not  about  the  DoD/C4ISR  Framework,  engineering 
notations/boxologies,  or  "creating  pictures  and  spreadsheets."  Integrated  Architectures  are  about 
"raising  the  bar"  on  defining  what  the  system  is:  the  business  processes,  systems  that  implement 
them,  and  the  rules  by  which  the  processes  and  systems  are  implemented.  “The  network  is  the 
system... "  Truly  integrated  enterprise  architectures  should  be  the  basis  around  which  a  “strategic 
information  asset  base”  is  built,  and  should  allow: 

o  The  multiple  CONOPs  the  enterprise  is  expected  to  encounter  to  be  defined  and 
recorded,  supporting  the  doctrine,  organization,  and  training  processes 
(DOT  of  DOTMLPF) 

o  The  multiple  SoS/FoS  solutions  to  meet  the  requirements  of  CONOPs  to  be  defined  and 
recorded,  supporting  the  securing  of  systems,  personnel,  and  facilities 
(MPF  of  DOTMLPF) 

o  The  use  of  portfolio  management  techniques  to  assist  leadership  in  the  analysis  and 
allocation  of  the  best  mix  of  systems  within  the  constraints  of  budget  and  schedule 
(L  of  DOTMLPF) 

I  recommend  a  pilot  program  be  started  at  JFCOM,  SOCOM,  or  TRANSCOM  in  order  to 
provide  the  multi-service  view  with  multi-service  ownership  of  assets  and  programs  across 
multiple  bases.  Upon  proof  of  concept  of  the  pilot  program,  it  should  be  migrated  DoD-wide. 
Efforts  including  GIG  NCES  CES  should  be  leveraged  as  much  as  possible  for  this  effort,  as 
there  is  significant  overlap  in  the  basic  functionality  to  be  accomplished,  not  only  regarding 
Mediation  Services,  but  regarding  dynamic  management  of  enterprise  assets  to  complete  the 
mission  and  tasks  at  hand.  Since  the  fruits  of  these  efforts  will  be  of  use  to  the  entire  DoD,  I 
believe  the  logical  owner  of  the  initiative  should  be  the  Joint  Staff  or  OSD. 

By  achieving  the  vision  of  an  architecture-driven  “strategic  information  asset  base,”  and  the 
standardization  of  portfolio  management  tools  and  techniques  DoD-wide,  we  will  achieve 
savings  through  economies  of  scale  as  well  as  gaining  efficiency.  We  will  accomplish  “in  the 
large”  what  the  transformation  community  is  trying  to  do  “in  the  small”  with  Net-Centricity;  to 
build  a  system-of-systems  that  keeps  us  inside  the  adversaries’  decision  cycles  via  correct 
distribution  of  limited  resources  more  quickly  than  our  adversaries  can  respond.  Can  we  afford 
to  do  this?  In  my  opinion,  with  the  defense  of  our  great  nation  at  stake,  we  can’t  afford  not  to. 
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DoD/C4ISR  Architecture  Background 

Clinger  Cohen  Act  of  1996:  CIO  Responsibilities  &  Duties 


‘Primary  Duty 


Definitions  extracted  from  ritle  44 


DoD/C4ISR  Architecture  Background 

Architecture  Definitions/Tenets 


•  C4ISR/DoD  Arch  Framework:  “...The  structure  of 
components,  their  relationships,  and  the  principles  & 
guidelines  governing  their  design  &  evolution  overtime...” 

•  Federal  CIO  Council: 

-  "...  a  strategic  information  asset  base,  which  defines 
the  mission,  the  information  necessary  toperform  the 
mission  and  the  technologies  necessary  to  perform  the 
mission,  and  the  transitional  processes  for  implementing 
new  technologies  in  response  to  the  changing  mission 
needs...” 

-  "...  The  primary  purpose  of  an  EA  is  to  inform,  guide, 
and  constrain  the  decisions  for  the  enterprise, 
especially  those  related  to  IT  investments...” 


DoD/C4ISR  Architecture  Background 

We’ve  Been  Doing  This  Since  1996... 


DoD/C4ISR  Architecture  Background 

Are  We  There  Yet...  Why  Not...? 


•  CIO’s  chartered  to  build  architectures;  but...  it 
was  an  “unfunded  mandate,..” 

•  CIO’s  spent  years  “doing  architectures...” 

“As  Is”  architectures  were  documenting  a  “moving 
target.!”  most  efforts  never  completed 

-  Viable  “To  Be”  architectures  seldom  “gotten  to” 

•  Drove  “Management  Question...:” 

-  How  best  to  capture  architecture  artifacts  from  new 
programs? 

Answer:  Make  them  document  architectures  as  part 
of  acquisition  process  (ORD  and  C4ISP) 

-  But.!  there  was  no  requirement  to  lie  program 
architectures  to  CIO’s  Enterprise  Arch  or  DoD  Data 
Standardization  efforts 


DoD/C4ISR  Architecture  Background 

Are  We  There  Yet...  Why  Not...? 


*  How  C4ISP’s  C4ISR  Architecture  Product  Requirements 
Generally  AccomplishedHH|^^H^^HH|^|^^H 

-  OV-1,  OV-2,  SV-1,  OV-6c: 

SME/Graphic  Artist  PowerPoint/Drawing  Tool  Engineering... 

-  OV-3/SV-6,  TV-1 : 

SME/Engineer-developed  Excel  Spreadsheets.. 

•  Usually  NOT  tied  to  the  community  CIO’s  enterprise 
architecture,  so  information  captured: 

-  Fell  on  the  floor... 


-  Couldn’t  be  tied  to  requirements}* 

-  Couldn’t  be  analyzed  on  an  enterprise  level 

a  Was  determined  by  whether  or  not  the  views  “looked  like”  a 
C4ISR  Arch  Framework  product,  rather  than  whether  it 
“answered  the  mail”  with  respect  to  the  requirement  delineated 
in  an  Integrated  Architecture 


WRT  to  Clinger-Cohen,  the  process  didn’t  “answer  the  mail...” 


(INTERIM  DEFENSE  ACQUISITION  GUIDEBOOK 
October  30,  2002) 


Architecture  Background 

Joint  C4I  Interoperability... 


Part  of  “The  Answer...” 

Joint  Capabilities  Integration  and  Development  Process  (JCIDS): 


•  Transition  Period: 

RGS  (CRD/MNS/ORD)  => 

JCIDS  (Int  Arch/ICD/CDD) 

•  Why  Change: 

-  Historically,  RGS  process  has 
been  good  at  systems  engineering 
“within  the  stovepipe” 

-  However,  RGS  has  been  “not  so 
good”  at  enterprise-wide 
requirements  management 

•  Integrated  Architectures: 
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Joint  Concepts 
Integrated  Architectures 


Top  Down,  Born  Joint 


-  Provide  engineering  discipline  to  design  of  the  Enterprise: 

>  Business  Processes  +  Systems  +  Rules  by  which  systems  built... 

>  Constraint:  that  which  one  has  financial  control/influence  over 

-  “Net  Centric”  transformation  enabler:  “raises  the  bar”  on  what  the 
system  is: 


The  Network  [S  the  System... 


(CJCSI 31 70.01  C,  20  Jan  03  Draft) 


Part  of  “The  Answer...” 

Joint  Capabilities  Integration  and  Development  Process  (JCIDS): 


(JFCOM) 

JCIDS 

Record Nation 

RcconuDHtdetions 

Support 

■—  &  Recommendations 

_ ^ 

CapabiJil>r  Needs 
DOTMLPF  Changes 

Capabilities- based  identification 
of  needs  combines join*  concepts 
and  integrated  architectures  with  analysis 


FCBs 

Battlespace 

Awareness 

(J2) 

C2 

(JFCOM) 

Force 

Application 

(J8) 

Protection 

(J8) 

Focused 

Logistics 

(J4) 

Net-Centric 

(J6) 


stem 

of  =  Roles  +  Systems 

(defined  (Hardware/ 
by  KSAs)  Software) 
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Operational  Views 


£  o 

<D  ™ 

»  4* 

CO  O 


Activities 


System-of 

Systems 

Solution 


ipability 


Time-Ordered 
=  Grouping  of  Activities 


. 


Systems  Views 


X 


JCIDS-Driven  Analysis  Requirements 

Enterprise-Wide  Capabilities  Analysis 


L 


Scenario  #1  Scenario  #2  Scenario  #3...  Scenario  #n 


%stem  or 
System 
(SoS) # 1 
SoS  #2 
SoS  #3 


SoS 

Measure 
of 

Merit 
|(Relative...) 


•  Analyze  SoS  s  across  ALL  applicable 
scenarios  within  the  Enterprise 

•  Enterprise  Examples: 

S  Navy:  Mission  Capability  Packages 
S  AF:  AF  CONOPs  (Global  Strike, 
Global  Response,  etc.) 

S  Joint:  Joint  Operational  Concepts/ 
Joint  Functional  Concepts 

•  Potential  Analysis  Threads: 

s  Systems  coverage  across 
scope  of  Activities 
s  Min  acceptable  solutions 


Dscjsjq/j  ArjsiJysj s/ 
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Chosen  *« 


Imns/ 

[CD 


C4ISP/ 


Acquisition 


ORD/ 


DD 


TEMP 


JCIDS-Driven  Analysis  Requirements 

Gap  Analysis 


Concepts 


Architectures 


National 

Military 

Strategy 


Joint 

Vision 


Joint 

Operating 

Concepts 


Joint 

Capstone 

Concept 


Service 

Operating 

Concepts 


Capability  Roadmap 
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Assessment 

capability  capability  capability 


systam  1 


systBin  2 


systBm  i 


systBm  i 


systBm  S 


systBm  6 


u 
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Resource  Strategy 
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training 

change 

sys  3 
SLEP 


sys  1 
block 

upgrade 


new  sys 
FOC 
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capability 


I  new 
organization 


sys  2 
end  of  svc  life 


JCIDS-Driven  Analysis  Requirements 

Enterprise-Wide  Capabilities  Analysis!  Span  DOTMLPfJL 


Sor joopt  DovoJopr/Jom 


DoDlC4\SFiArzh 
J  rite  sj  rated  Arabltectera: 


Doctrine 

•  Render  info  into  Pictures 

Development 

•  Support  Acq  Docs 

Support 

\ 

Training 

Support  Acq 

Docs 

Strategic 

~W  C*  A  • 

Train!  up 


Support  Acq 
Support  Leadership 
Understanding  of 
Doctrine/CONOPS 


Decision  ArraJyol s/ 
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Operations  P\rraJysl 
JVJodellnp  &  SlrnuJotl 


Asset  Base 


I 


Support  Analysis  of: 

-  Organizational 

-  Materiel 

-  Personnel  I 

-  Facilities 


Prop  ram  Support 
Aop ulsltlon  Support 
rlrranolnl  PJnmipernen 


|MNS/ 
[CD 


C4ISP/ 


JCIDS-Driven  Analysis  Requirements 

Implication;  Need  Near-Real  Time  Total  Asset  Visibility 


Materiel 


Need  Near  Real-Time  Asset  Visibility  to  Manage  ALL 
Aspects  of  DOTMLPF,  with  ties  to  Financial  and  M&S 


Endgame  Recommendation 

Tie  Portfolio  Management  to  Integrated  Architectures 

•  What  is  Portfojo  Management? 

-  Software-supported  management  information  system  for  program, 
asset,  and  activity  management 

>  Web  based  system  for  dynamic  updating 

>  Robust  technology  for  managing  any  type  of  corporate  asset 

>  Leverages  existing  automated  data  collection  systems 

>  Views  are  customized  for  each  level  of  management  oversight 

•  Standardizes  reporting  across  the  organization 

-  Reduces  level  of  effort  and  turn-around  time  for  status  updates 

-  Minimizes  the  need  for  ad  hoc  reports 

•  Tracks  performance  metrics  in  near  real  time 

-  Tracking  indicators  highlight  problems  for  rapid  diagnosis  and 
resolution 

-  Collects  performance  histories  over  time  (trend  analysis) 

-  Tracks  ownership  and  status  of  deliverables 

-  Visual  status  prompts  pinpoint  high  value/high  impact  issues  for  risk 
mitigation 


Endgame  Recommendation 

Tie  Portfolio  Management  to  Integrated  Architectures 


Business 
^  Focus^ 


Group/ 

Program 

Focus 


Team  / 

Project  Focus 


Quality  Assessment* 


Budget  Assessment*:  value  trend 


Choose 


Annual  Plan 


Execute 


I  nvestor  Mi; 


Workbook 


All  Views  User  Profile-based:  User  profile  determined  by  role; 
user  only  sees  information  appropriate  to  their  role 


Endgame  Recommendation 

Tie  Portfolio  Management  to  Integrated  Architectures 


•  Recent  Positive  Developments: 

-  GIG  Net  Centric  Enterprise  Services  Core  Enterprise  Services 
definitions  are  maturing,  and  can  possibly  be  leveraged  for 
mediation  services  and/or  lA/Security  Services 

-  Recent/Draft  Documents/Guidance: 

>  OSD  03246-04,  22  Mar  04 

v  Subject:  Information  Technology  Portfolio  Management 

✓  ...While  the  guidance  specifically  addresses  IT  portfolios  and  a 
process  for  making  tradeoffs  among  IT  projects,  the  IT  portfolio  is 
part  of  the  Departments  broader  portfolio  of  investments... 

>  DoD  Management  Initiative  Decision  918  (DRAFT) 

✓  Subject:  Establishing  Portfolio  Governance  for  the  Global 
Information  Grid  (GIG) 

s  ...ensures  that  the  Department’s  Information  Technology  (IT), 
including  National  Security  Systems  (NSS),  investments  in 
information  capabilities  and  services  are  managed  as  portfolios^ 


Endgame  Recommendation 

Tie  Portfolio  Management  to  Integrated  Architectures 


Positive  Developments  Since  Paper  was  Written  (cont.): 

-  Recent/Draft  Documents/Guidance  (cont.) 

>  DoD  Business  Modernization  and  Systems  Integration  Office  requested 
Industry  Adviosry  Council’s  Enterprise  Architecture  Special  Interest 
Group  to  develop  whitepaper: 

✓  Subject:  Integrating  Enterprise  Architecture  and  Portfolio  Management  Within 
BMSI  (Domains:  Acct  &  Fin,  Acq,  HRM,  Inst  &  Env,  Log,  Strat  Plan  &  Budgeting) 

✓  To  be  published  soon... 

>  Observation:  these  documents  primarily  deal  with  IT  ONLY.  Remember 
we  need  to  manage  ALL  aspects  of  DOTMLPF..*  plus  schedule...  plus 
finances...  and  tie  it  to  M&S... 

Endgame  Recommendation: 

-  Tie  Enterprise  Architectures  to  Portfolio  Management 

-  Leverage  GIG  NCES  CES  as  Much  As  Possible 

-  Do  proof-of-concept  at  JFCOM,  SOCOM,  or  TRANSCOM  to  prove 
Joint  viability 

-  Benefits: 

>  NRT  Asset  Visibility  aids  in  monitoring  progress  from  as-is  to  to-be 

>  Analysis  of  Program  Slips,  “what  if  s”,  etc.  greatly  facilitated 

>  Key  start  towards  Net  Centric  Warfare.. ;f 


Integrated  DoD/C4ISR  Architectures 
It’s  Not  About  The  Framework. . . 


Lawrence  P.  McCaskill 


Manager,  C4ISR  Architecture  Requirements 
Whitney,  Bradley,  &  Brown,  Inc. 
Imccaskill@wbbinc.com 


Presented  to: 

2004  Command  and  Control  Research  and  Technology  Symposium 
The  Power  of  Information  Age  Concepts  and  Technologies 
15-17  Jul  2004 


Corporate  Profile 


•  Website:  www.wbbinc.com 

•  Client  Base: 

-  U.S.  Departments  of  Defense,  Transportation 

-  UK,  Australian,  Italian  and  German  Ministries  of  Defense 

-  US  and  Allied  defense-related  businesses 

-  Non-defense  corporations 

•  Contracting  Vehicles: 

-  Government  Services  Administration  (GSA)  (MOBIS  Schedule) 

-  Sub-contract  to  Coalescent  Technologies  Corporation  (CTC) 

-  Direct  Contract 

•  Founded:  1981 

•  Ownership:  Employee-owned 

•  2003  Revenues:  >  $23  Million 

•  Employees:  100+ 

•  Locations: 

-  Vienna,  VA 

-  Hampton,  VA 


m  WBB  Core  Competencies 


•  Core  Competencies; 

-  Concept  Development  -  DoD/C4ISR  Architecture 

■  Operations  Analysis  Development 

^B  Program/Financial/  Decision 

Acquisition/JCIDS  Support/Portfolio  Mgt 

Support  -  Training 

•  Additional  Strengths: 

-  Battlespace  Knowledge 

-  We  Know  the  Players 

>  DoD  and  other  Government  Agencies 
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M  What  WBB  Brings  to  Bear 


Senior  Warfighters 
from 

All  Services 

Current  operations, 
logistics,  and 
acquisition  expertise 

Detailed  knowledge  of 
the  decision  making, 
procurement,  and 
budget  processes 


Experienced  Military 
Engineers 

-  Operational  Military 
and  Prime 
Contractor  design 
experience 

-  Seasoned  Program 
Managers  of  large 
weapons  systems 
and  programs 


Experienced  Military  Operations  Research  Analysts 

-  Senior  Operations  Research  Analysts,  with  appropriate 
core  models  and  tools 


-  JCIDS  +  DoD/C4ISR  Arch  subject  matter  expertise 


DV9IJ  311 
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So  What? 

Implications:  How  WBB  can  help  connect  the  Dots.., 
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Strategic 
Information 
Asset  Base 


MNS/ 

ICD 


4ISP/ 


ORD/ 


Concept  Development 


ConOps  forms  the  foundation  for 
requirements  development,  systems  analysis 
and  integration: 

-Operationalizes  new  technologies,  future  concepts 
-Clarifies  emerging  requirements 
-Establishes  a  Joint  perspective 
-Identifies  issues  requiring  resolution 

Gather  Data: 

-  Study  the  applicable  technology  and  project  the 
expected  mission  environment  not  only  on 
systems  being  replaced,  but  on  force  structure 
and  mission  environment 

Synthesize: 

-  Apply  broad  operational  experience  of  WBB 
Navy/Marine/Air  Force/Army  personnel  to  develop 
employment  concepts 

-  Focus  on  the  differences  new  technology  &  new 
environment  will  create  from  the  way  we  do 
today’s  missions 

Validate: 

-  Validate  new  concepts  with:  Warfighters, 
Designers,  Modelers/Analysts 


-Achieves  consensus  among 

•  Warfighters 

•  Requirements  and  acquisition  communities 

•  System  developers 

-Gains  broad  support  for  new  and  ongoing  programs 
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Operations  Analysis 


Cost-effective  solutions  to  meet  requirements 

End-to-end  analyses  focusing  on  particular  measures  or 
warfare  areas 

-  Optimization  and  Stochastic  tools 

“Bookends”  I  leading  and  overseeing  analytical  efforts 

-  Study  plan  development 

-  Identification  of  measures 

-  Scenario  development 

-  Interpretation  and  packaging  of  results 

Consulting  to  analytical  staff 

-  Red  teams 

-  Supervision  of  analytical  teams 

-  Analysis  training 

10  consultants  with  OA  degrees;  23  OA  practitioners 


V  c* 


Models/T ools 
Processes/Data 


Must  Be  In  Balance 


£oncepts/Context/ 
Capabilities 


Program/Finance/ 

Acquisition/JCIDS  Support  Examples 


Government 


JSF/STOVL  JSF 
JDAM  PIP 

DD-21  including  C4ISR 
TAD-SE  (CSFAB,CIDWG,SETs) 

NSFS  C4ISR/LAW  Center 

MV-22  ConOps/C4ISP 

ONR-CCID 

ASCIET  /  JADO/JEZ 

TCS/DSEAD  TacMemo 

N64  Info  Ops/Global  WG 

COBRA  BALL/CS/RJ/SS  Ops  Guides 

N865  Theater  Air  and  Missile  Defense 

ASD/C3I  Operational  Architecture,  ISR-ICSP 

Sustaining  Engineering 

MRE/VTUAV/UCAV 

Avionics  Master  Plan 

F-15  C-E  Roadmap 


CVNX  C4ISP 
JCC(X) 

NWPS/NSWPC 
Shriever  2001  WG 
QDR  Support 
Joint  Assured  Access 
CSA/E-2C 
SIAP  SE 

Stk  Master  Plan/NAMP 
AIM9X/JHMCS 
JFACC  AP— 


B-1/B-2 

NLW 

F-15E 

JBC 

JICO 


0- 
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NORTHROP  GRUMMAN 

Raytheon  a 

ay  the  on  Systems  Company 

Industry 

Discoverer  II 
CAC2S 

F/A-18G  ConOps 
JASSM  and  CASOM 
AIM-9X 
GEN  III  FLIRs 

Tactical  Operations  Centers 

FOPEN/FOREST 

MIRFS 

USCG  Deepwater 

SFW 

FCS 


Mako  LCA/AT 

Tomahawk  III  /  IMA  /  IV 

JSOW 

ATF COE 

F-14  /  LANTIRN 

Naval  Fires  Network 

CVN77 

UCAV/MRE  UAV 

JHMCS 

MALD 

LOCAAS/MMC/SDB 
GE  110  SLEP 


Integrated  DoD/C4ISR 
Architectures 


JCIDS  Reguires  Integrated 
Architectures  for  NR-KPP 


Mandatory  Product  Views  for  CDD,  CPD 
ISP:  OV-1,  2,  5,  6c;  SV-4,  5,  6;  TV-1 

Integrated  Arch  Requires: 

-  Understanding  of  JCIDS  Process 

-  Understanding  of  Joint  and  Service 
Operational  and  Functional  Concepts 

-  Understanding  of  DoD  Arch 
Framework  Product  Interrelationships 

-  Interconnectivity  between 
Architecture  products 

>  Facilitated  by  Automated  Tools 

>  Tools  generally  “user  hostile,” 
experienced  tool  drivers  a  must 


Guidance 

JCIDS,  Architecture,  and  the  Acquisition  Process 
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JCIDS  Integrated  Architectures 

Joint  Staff  viewing  Capability  as  an  time-ordered  set  of  OV-5 
Activities,  and  maps  these  to  systems  in  order  to  do  gap  analysis 


. ,  -k-r 
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Capabi  I  ities-Based  Methodology 
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Relationships  Between  Products 

(Operational  to  System  Arch  Cross  Checks) 


Abstract  Requirement 


Jo....... 
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Physical  Implementation 


The  key  take-away  with  respect  to  cross-walking  architecture  views:  Operational 
Architectures  represent  the  Operational  Requirement.  The  Systems  Architecture  is 
e  of  many  possible  Physical  Implementations  of  the  Operational  Requirement 


Proven  capability  in  developing  Integrated  DoD/C4ISR  Architectures... 


Where  Enterprise  Architecture  “Fits” 

Relationships  Between  Architecture  and  Systems  Engineering 


“Blue  Sky”  Vision 


Understanding 

INFORMATION  AGE 

Warfare 
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Warfare 

IWrrJif  5-. 

P.Pr-is* 

C.CJM- 

Training 
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Program  supporlmg 
a  capability 

Program  supporting 
a  capability 

Program  supporting 
a  -capability 

I  AF  Planning  and  Prograr 


How  Washington 
Works; 

-  Requirements 

Hppbs=>ppbe 

H  Acquisition  System 

-  Congress 

-  Networking 

Manpower,  Personnel,  &  Training 
Operations  Analysis 
GPS/Precision  Targeting 


J  Acquisition  Process:  “New"  versus  “Old” 
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Decision  Support 


Provides  knowledge,  facilitation,  and  tools  to  support  decision  makers 
at  any  level  of  an  organization 


Helps  define,  organize,  analyze,  and  synthesize  key  decision  variables 
to.  arrive  at  the  best  solution  within  the  context  of  customers’  needs 


Hferifefc  tor's  Needs 
Module 
<l«0M nys 


Programmatic 

Module 


Benefit 
Assessment 


Optimization 

Module 


PrOjfrdtS  scJfctfd 
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Funding  shortfalls 


Discovery  Framing  ^  Evaluations  Cfia-iet 


T 


jL 


Collaborative  Facilitation 
(Group  Systems) 

Analytic  Hierarchy  Process 
(Expert  Choice) 

Portfolio  Management 
(ProSight) 

Relational  Databases/ 

MS  Access 

Programming  Support 


Decision  Support 

Scorecard  Overview 


Scorecard  of  I  nterest 


Portfolio  of  I  nterest 


3  ProSight  Portfolios  -  Scores  ^rd  -  Microsoft  Internet  Explorer 


SCORECARD 


Scorecard : |5.3  IT  Operations  Ri 


Portfolio: |lT  Products  and  sjCce 


Summary 


Values 


(portfolio  view) 


Projects 


(investments) 


Health 

Assessment41 


Shut  Down 
Date 


Customer  Quality 
Satisfaction  Assessment* 


Uptime 
(Actual)  <-- 


IT  Products  and  Services 


3-D  Seismic  Application 
3-D  Seismic  Workstations 
Cable  Drilling  Rigs 
Crop  Drying 
EBB 

Emergency  Preparedness  Program 
Enhanced  Oil  Recovery  System 


Phase  Out 
Phase  Out 


84.59  O 


J£sr± 


Operational^ 


^Ogerationa^ 


a^Pregarati' 


Unknown 
Unknown 
Unknown 
Unknown 
Unknown 
,  Unknown 
■  Unknown 


0.70 

92.00 


Exploratory  Wells 

O 

Beta 



★ 

o 

★ 

_ 

FERC-EBB  Compliance 

O 

Negotiate 

78.00  • 

• 

• 

O 

Fractioners 

★ 

Operational 

97.00  ★ 

O 

I  •  I 

★ 

O 

Fuel  Cells 

★ 

Operational 

?nns> 

77.00  • 

O 

V*  J 

• 

★ 

Gas  Turbo  Expansion  Turbine 
Geological  Mapping  System 

Guided  Boring  Systems 

Helium  Recovery  Contract 

it 

Requirements 

88.00  O 

It 

it 

if 

Ogeratjona^^ 

99.00  ★ 

ic 

O 
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if 

Phase  Out 

Q3  2000 

78.00  • 

if 

/  ^ 

♦ 

• 
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 Desjgn 

99.00  ★ 

4r 

/  * 

★ 

♦ 

Category 


Horizontal  Well 

Intelligent  Robotics  Inspection  Des 
LDC  Customer  Rate  System 
Magnometer 


^Acquisitic 


.  Unknown 
Unknown 


98.00 

99.00 


MUin  Cvchpm 


Scorecard  provides 
detailed  view  of  key 
business  and  project 
parameters 


al  Contract 

O 

* 

Operational 

Uggrade 

■  Q3  2000 

Unknown 

0.50  • 

99.00  ★ 

/  * 

★ 

★ 

• 

★ 

★ 

lucation  Training 

★ 

Operational 

.  2002 

78.00  •  k 

r  ★ 

★ 

• 

• 

4 

★ 

ERP  Project  Preparation 

_  Unknown 

89.00  Ot 

★ 

★ 

★ 

1  ★  ■ 

► 

Cell  Value  or  I  ndicator 

(manual  or  extracted  from  other  data  sources) 


Decision  Support 

Dashboard  Overview 


ProSight  Portfolios  -  Scorecard  -  Microsoft  Internet  Explorer 


File  Edit  View  Favorites  lo 


ffi  .  1  1  .  .  . 

3  Dashboard  for  Assets  -  Asset  Type  -  Microsoft  Internet  Explorer 

SCORECARDr  DASHBOARD 


Assets 


3-D  Seismic  App 
3-D  Seismic  Woi 
Cable  Drilling  Ri> 
Cogeneration 
Crop  Drying 
EBB 

Emergency  Prep 
Enhanced  Oil  Re 
EPA  Acquifier  St 
Exploratory  Wei 
FERC-EBB  Compl 
Fractioners 
Fuel  Cells 
Gas  Turbo  Expai 
Geological  Mapp 
Guided  Boring  S 
Helium  Recover 
Horizontal  Well 
Intelliaent  Robe 


Dashboard  |  View  |  Setup  |  Help 


Dashboard:  |  Asset  Type 


- 1  Portfolio:  Assets 
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Asset  Type:  value  distribution 


SCORECARD 


Scorecard :  jHealth  Assessment* 


w  Portfolio  :|lT  Products  and  Services 


Scorecard  |  View  |  User  |  Setup  |  Help 
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